layman question: Why use atan2 at all rather then the original volition function? What's the performance vs inaccuracy trade-off being made here?

layman question: Why use atan2 at all rather then the original volition function? What's the performance vs inaccuracy trade-off being made here?

The primary reason is for the special case at 0, 0. See the comment on the previous PR:

According to DahBlount:

Most atan2 implementations for a long time had problems when the inputs were close to machine epsilon or when x was less than or equal to 0

And according to z64555:

Modern versions of C++ should have an atan2() that works correctly when the inputs are at 0 or near epsilon of the floating point specification, meaning Volition's workaround shouldn't be needed anymore.

So this removes atan2_safe and changes all instances to atan2. Consequently, the angle range in FRED now shows as [-180, 180] as expected.

In most respects the library function is to be preferred over the hand-rolled function, so changing to atan2 was a good idea for the general case. But for the special case of 0, 0, this devolves into gimbal lock, which will cause the viewpoint to flip 180 degrees as you noticed. So all this is really doing is adding back handling for the special case.